5 dpo - 2000 Team Description for Year 2004

This paper briefly describes the design principles of the hardware and software of 5dpo-2000 team. An evolutive approach is presented as the robots are constantly being improved with new capabilities added or removed as the experience from previous competitions is used to access their advantages or disadvantages. Also is presented the use of this robots as a tool and motivator for some experiments done by students of graduate and undergraduate courses. Some design options that proved extremely important for rapid development are presented and the advantages explained. Relevant control issues are also addressed, especially some details of the application of Kalman Filters in the design of the localization algorithms. 1 Mechanical Aspects Mechanically, the 5dpo-2000 robots are based on an aluminum chassis that forms a building like structure. Only the back of the robot has a wall from the bottom to the top, the other sides are open to allow an easy access to the different modules. On the lowest module we have the motors. They are directly attached to a gearbox that is also attached to the wheels. Also in the bottom of the robot are the batteries, thus keeping the robots center of gravity very low. Fig. 1. The mechanical structure of a 5dpo-2000 Team robot exposed This is an area where changes are costly, both in terms of time and money spent. For that reason it is where there is the least evolution, unless a strong factor enters and makes it very important. This is the case of moving the locomotion strategy from a wheel chair configuration to a omni directional one. In the previous year we changed the robot mechanics to the one, show in figure 1, with three omni-directional wheels. The three (one perpendicular to other two) wheels do allow for omni directional movement but the rear wheel must account for all the lateral movement and is heavily strained. Also, to maintain the robot heading, the other two wheels must be stopped under a considerable rotating torque and that is also very demanding for the motors. One problem that was frequently seen is that is very easy to loose gripe and slip. That is very unfortunate because the maneuver is compromised and the localization information that come from odometry becomes very misleading. This effect depends on the type of the carpet and was specially bad when one or more of the wheels were over the painted white lines. To minimize this problem the current mechanical design has four omni-directional wheels with the axes forming a cross. The front and rear wheels may be smaller then the other wheels for extra torque. The back wheel also has a spring suspension mechanism to make sure that all four wheels always touch the ground. This wheel configuration solves most of the previous problems but has more wheel/motor pairs than there are degrees of freedom. We have four controllable wheel speeds versus only three independent velocities (Vx, Vy and •). The controller algorithms must ensure that the set speeds correspond to an admissible (Vx,Vy,•) configuration. If that does not happens, there will be some unpredictable slippage on one or more wheels. To minimize the effects of that situation and also to increase the global accuracy of the odometry system there are two sets of encoders: the first set is connected to each motor axis; the second set touches the ground directly via another small omni-directional wheel. The free running omni-directional wheels are on the same axis of each other traction wheels. Comparing outputs from the two sets of encoders enables slip detection. That is also used to prevent the robot from pushing an unseen obstacle. 2 Hardware Architecture All motors are DC motors with a gearbox and are driven by an in house developed driver circuit board. It based on the Atmel ATMega8 microcontroller. All motors communicate via serial RS232 protocol. Each board drives one motor an can interface to tho dual phase incremental encoders. That information is processed and the relative number of encoder steps are sent to the PC for trajectory estimation. It is also sent the actual motor current to improve the dynamics and to detect some fault conditions: a burned MOSFET or motor; a situation where the robot is stuck between undetected obstacles or tangled with other robot. In previous years it was used a camera mounted on a pan system. Being able to see the 40 degrees of the field (in the pan-able direction) was a design trade-off between using all the camera resolution on a limited field of view (and have a good spatial resolution on that image) and the inevitable presence of a lot of blind spots that could be only covered when the camera was rotated. The main advantage was that the robots could see the ball very far away (almost from one side of the field to the other) even when using a very low image resolution (196x144 pixels). Advances on the on-board computing power made that advantage less important and the ability to cover the all 360 degrees of vision justifies a omni-directional vision system. The robots' vision system is being changed to a catadioptric system that allows omni-directional vision arround the robot by use of mirror with hyperbolic shape. Fig. 2. The three wheeled robot of the 5dpo-2000 Team In Padua The only extra actuator is an electromagnetic kicking device. In previous years, pneumatic and spring based kicking devices where tested but the pneumatic system proved very bulky and the spring kicker had the disadvantage that it does not allow to set the kicking strength instantaneously as the electromagnetic kicker does. By choosing the pulse length it is possible to choose the kick strength if there is need to make a pass or throw the ball to an empty area where it can be caught by another robot. NiMh batteries (24.4V/6000mAh) power the robots. A Switching Mode power supply is used to convert 24V to 12V,5V,3,3 and -12V to power the general consumer PC motherboard and the rest of the electronics. Previously there were two active IR distance sensors but their performance was very poor, specially because of false obstacle readouts. The on board PCs have CPUs in the order of 700Mhz and vision acquisition is based on a BT878 chip PCI card. This configuration allows a very small latency in image acquisition but some noise is acquired in the analog path. Previously, the robots and Supervisor used IEEE 802.11b compatible wireless LAN cards. The used card only allowed for 2MBits/s maximum bandwidth and the practical throughput was even lower. Worse, under the normal circumstances of a RoboCup competition, there were cases where the communication became so unreliable that the contact could be completely lost for more than 20 seconds. The present system is Bluetooth based and, while it has an even lower bandwidth it seems a lot more reliable. 3 Software Architecture 5dpo-2000 team is based two different software modules. For each robot there is the HAL (Hardware Abstraction Layer) and the DEC (DEcision and Cooperation) module. The HAL is responsible for controlling the robot and also for gathering information from its sensors and analyzing it in an appropriate way. It then sends filtered high-level information to the DEC module that is responsible for individual and cooperative decision-making. Communication between the DEC modules from different robots implements cooperation and coordination. The HAL performs the image acquisition and processing and gateways other sensor and control information. Image processing is done based on previous calibration of colors, forming color blobs and detecting edges. It performs also object recognition by grouping color blobs in the case of poles and by analyzing the relative size and world position in the case of balls and goals. For example, in one local RoboRup tournament the spectator seats where red and easily mismatched for a ball, but that would usually mean a very big and far away ball so that interference could be easily filtered out. The Supervisor module is only used to signal the robots to start or stop and to collect the information passed between robots. For now, there is no coordination information sent from the Supervisor module to the robots. As the Supervisor listens to all the robots' communication it can show the estimated position of each robot, the perceived ball position and also detect if the robot is active. 5DPO Team Architecture